コレクションパイプラインは、一連の演算として計算を構成するプログラミングパターンです。演算は、コレクションを1つの演算の出力として受け取り、次の演算に供給することで構成されます。（一般的な演算は、フィルター、マップ、およびリデュースです。）このパターンは関数型プログラミングで一般的であり、ラムダを持つオブジェクト指向言語でも一般的です。この記事では、このパターンに不慣れな人にパターンを紹介し、コアコンセプトを理解して、ある言語から別の言語へアイデアをより簡単に移行できるようにするために、いくつかのパイプラインの形成方法の例を使用してパターンについて説明します。

オブジェクト指向言語は、クラスと呼ばれるモジュールにプログラムを分割します。各クラスには、データ（フィールド）とメソッドで構成される機能が含まれています。（すべての言語がこれらの用語を使用しているわけではありませんが、ここではこれで十分です。）言語には、クラスの機能に他のクラスがアクセスできるかに関するさまざまなルールがあり、これらは多くの場合、クラスに適用されるアクセス修飾子に基づいています。

プログラム要素（通常はクラス、メソッド、またはフィールド）のアノテーションは、そのプログラム要素に追加されたメタデータであり、追加のコードでその要素を修飾するために使用できます。

スーパークラスの呼び出しは、OOフレームワークで時々現れる小さなスメル（またはアンチパターン、お好みで）です。その症状は非常に簡単に見つけることができます。フレームワークに接続するために、スーパークラスから継承しています。ドキュメントには「自分で何かをするには、processメソッドをサブクラス化するだけでよい。ただし、メソッドをスーパークラスへの呼び出しで開始することを忘れないことが重要です」と書かれています。例としては、次のようなものがあります。

オブジェクトについて学ぶとき、通常は、オブジェクトがインスタンスとクラスという2種類のデータをキャプチャできることを学びます。インスタンス変数が最も一般的なケースで、データはオブジェクトの各インスタンスによって異なります。静的変数とも呼ばれるクラス変数は、クラスのすべてのインスタンス間で共有されます。すべてのインスタンスが同じ値を指し、変更はすべてに反映されます。クラス変数は、特に可変のクラス変数は、インスタンス変数よりもはるかに一般的ではありません。

私は長い間、プログラミング言語における静的型付けと動的型付けの間の議論について何も書くのを嫌がっていました。これは、人が聞いて議論するのではなく、議論に駆り立てられているように見える感情的なトピックの1つです。しかし、それについて何度か聞かれたので、私自身の個人的な経験を共有します。私は誰にも何かを納得させようとしているわけではありませんが、誰かがその中に思考の糧を見つけてくれることを願っています。

プログラミングにおいて、オブジェクトの基本的な概念は、データと動作のバンドルです。これは、関連する関数セットを作成するときに、共通のデータコンテキストを提供します。また、オブジェクトがデータへのアクセスを制御できるように、データ操作へのインターフェイスを提供し、派生データをサポートしやすくし、データの無効な変更を防ぎます。多くの言語は、オブジェクトの定義として機能するクラスを定義するための明示的な構文を提供しています。ただし、ファーストクラス関数とクロージャを持つ言語がある場合は、これらの構造を使用して、オブジェクトとしての関数パターン（もともとユージーン・ウォーリングフォードによって記述された）を使用してオブジェクトを作成できます。

Javascriptでは、promiseは非同期操作の保留中の結果を表すオブジェクトです。これらを使用して、コールバックを提供することにより、非同期操作が完了した後にさらにアクティビティをスケジュールできます。

動的言語への関心が高まっているため、ラムダ（クロージャ、匿名関数、またはブロックとも呼ばれる）と呼ばれるプログラミングの概念に出会う人が増えています。C/C++/Java/C#言語のバックグラウンドを持つ人はラムダを持っておらず、その結果、ラムダが何であるかわかりません。簡単な説明を以下に示します。ラムダを持つ言語で十分なプログラミングを行ったことがある人にとっては、これは面白くないでしょう。

人々にオブジェクト指向を教えたい場合、どの言語を使用する必要がありますか？

多くのプログラミング環境で、データ構造をリストとハッシュマップの複合として表現することが一般的になりました。ほとんどの主要言語は、これらのデータ構造の標準バージョンを、特にコレクションパイプラインなどの豊富な操作範囲とともに提供し、これらを操作します。これらのデータ構造は非常に柔軟性があり、処理や操作が簡単な方法でほとんどの形式の階層を表現できます。

クラスに保護アクセス修飾子を持つデータがあるのは良いOO設計ですか？

C#に初めて出会ったとき、私は最初からプロパティの概念が好きでした。C++/JavaのgetXおよびsetXの規則は、私にはいつもかなりばかげているように思えました。obj.X = other.Xと書く方がはるかに自然です。getおよびsetメソッドを備えたプロパティを提供することは、一般的な規則を言語の自然にサポートされる機能に変えます。

公開されたインターフェースは、私が（最初にリファクタリングで）定義されているコードベースの外で使用されるクラスインターフェースを指すために使用した用語です。そのため、Javaのpublicよりも意味が深く、実際にはC#の非internal publicよりもさらに意味が深くなります。IEEE Softwareのコラムで、公開とpublicの区別は、実際にはpublicとprivateの区別よりも重要であると主張しました。

Rubyで最も人気のある機能の1つは、メタプログラミングのサポートです。これは、新しいキーワードのようなものを導入する、言語自体を変更するように機能する機能です。

時々、Smalltalkを入手して、何が話題なのかを試してみたいという人に遭遇します。私の古いお気に入りの入門Smalltalk書籍は絶版になりましたが、今ではここから、他の多くのSmalltalk関連資料とともにダウンロードできることがわかりました。この資料は、リエンジニアリングパターンに関する優れた書籍の共著者であるステファン・デュカスによってホストされています。

ドメイン固有言語（または実際には任意のコンピュータ言語）について話すときに飛び交う一般的なフレーズは、ノイジーな構文です。RubyはJavaよりもノイズが少ないとか、外部DSLは内部DSLよりもノイズが少ないと言う人もいます。構文ノイズとは、人が本当に言いたいことの一部ではなく、言語定義を満たすために存在する余分な文字のことです。ノイズ文字は、プログラムの意味を不明瞭にし、その動作を解読することを強いるため、良くありません。

Web開発者は、ブラウザで実行される他のテキストソース言語にコンパイルするCoffeeScriptやSCSSのような言語をますます使用しています。このようなソース間コンパイラ（トランスパイラとも呼ばれます）は新しいものではなく、Cfrontは初期のC++でターゲットCコードを生成するためによく使用されていました。しかし、私にとって、CoffeeScriptとSCSSを透過的なコンパイラとして選択する違いがあります。

モジュールによって提供されるすべてのサービスは、ストレージまたは計算によって実装されているかどうかを隠す均一な表記法で利用できる必要があります。

--バートランド・メイヤー

バートランド・メイヤーは、彼の非常に影響力のある書籍オブジェクト指向ソフトウェア構築でこの原則を作りました。

この原則の重要な点は、人オブジェクトがあり、その年齢を尋ねる場合、年齢がオブジェクトの保存されたフィールドであろうと計算された値であろうと、同じ表記を使用する必要があるということです。これは事実上、人のクライアントは、年齢が保存されているか計算されているかを知る必要も気にする必要もないことを意味します。

goto（以前はJAOOとして知られていました）は、私のお気に入りの会議の1つです。彼らは長年にわたって、効率的でフレンドリーな組織と組み合わせた、質の高いコンテンツを維持するために素晴らしい仕事をしてきました。そのため、会議の過剰消費は一般的に会議恐怖症につながりましたが、オーフスへのやや複雑な旅行に出かけるときは、依然として楽しい期待感を感じます。